你有沒有過這種時刻：你花了好幾週打造了一個功能，程式碼乾淨得像藝術品，單元測試 100% 覆蓋率，部署順利，結果上線後卻沒人用？

產品經理說這是「策略性需求」，但你心裡明白，這東西沒解決任何真實問題。更糟的是，當你試著在會議上提出技術建議，卻被一句「這不在我們當前優先級」打發。

你心想：如果我能影響產品方向，會不會完全不一樣？

前幾天我們聊了工程師應該具備商業思維，並且學習以商業思維思考技術，了解 PM 規劃功能的真實動機，並且主動與跨部門的團隊交流。今天我們再從工程的角度出發，看看可以怎麼從工程影響商業。

技術影響者

技術影響者很厲害，他們能把技術決策和業務目標掛鉤，比如優化網站載入速度來提升轉換率。

• 他們看到行業的風向，知道什麼技術對公司的未來有幫助
• 他們畫出技術路線圖，影響產品的優先級

舉個例子：產品經理要求你實作一個花俏的動態彈窗。作為技術影響者，你會問：「這彈窗對用戶有什麼價值？對 SEO 有沒有影響？如果直接用 SSR 顯示在畫面上，能不能既滿足需求又提升搜尋流量？」

1. 別只埋頭寫程式碼，抬起頭看風向

成為技術影響者的第一步，是從「解決當前問題」進階到「預測未來挑戰」。這意味著你要開始關注更大的圖景：

• 偷瞄行業趨勢：每週花 15 分鐘看看 Hacker News 熱門文章，或翻翻大型 conference 的最新技術亮點。
• 搞懂公司想幹嘛：找機會聽聽高層的季度分享，假如公司計劃進軍新市場，你可以提出更好協作的系統架構，因應未來可能會混亂的情境。
• 拋出大膽想法：下次產品會議，別只顧著點頭，試著提出自己的看法，嘗試要求資源讓自己嘗試

2. 畫一張屬於你的技術路線圖

技術影響者不只是跟著 PRD 跑，他們會主動畫出技術路線圖，告訴大家「這是我們該去的方向」。怎麼做？

• 跟大佬聊聊：找個機會跟 CTO 或產品負責人喝杯咖啡，問：「我們未來兩年的技術痛點是什麼？」比如，如果產品負責人說「想要追求網站的流量」，可以提出 SSR 之類的解決方案。
• 想遠一點：每次實現功能時，問問自己：「這東西未來會不會卡住我們？」，比如現在的架構不利於多團隊擴展，是否需要進行專案切割，或是採用 monorepo 的架構。
• 對團隊有幫助的事情：開發總有些事情困擾著你，你可以嘗試把困擾以及解決方案列出來，直接跟團隊的所有人討論你的計劃。

3. 像個領袖，而不是碼農

技術影響者得有點領袖氣質。這不是要你變成開會機器，而是要你在關鍵時刻站出來：

• 主動扛責任：下個跨部門項目，毛遂自薦負責技術部分。比如，帶頭評估新功能的技術可行性，和 PM 一起定優先級。
• 分享你的藍圖：在團隊會議上，講講你的技術路線圖怎麼幫公司。比如，「這新架構能讓我們在未來獲得更多的流量」
• 別怕被挑戰：如果 PM 說你的提案太貴，別吵架，聽聽他們的顧慮，然後調整方案。比如，「好，我們先做個 POC，降低風險。」

結語

作為技術影響者，你不再只是把 PRD 變成程式碼，而是開始嘗試決定公司未來的技術方向。這需要你抬起頭看行業風向、畫出屬於你的路線圖，還要像領袖一樣帶隊往前衝。